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Technical Field 

The present invention relates to electronic 
commerce. More particularly, the present invention 
relates to an electronic bill payment system with 
merchant identification. 
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Background Art 



It has been common for many years for consumers to 
pay bills by way of a personal check written by the 
consumer to the order of an entity and delivered to\ 
5 that entity by mail or in person. With the 

proliferation of computers interconnected to computer 
networks, particularly the Internet, consumers can now 
pay bills electronically. However until recently it 
was not possible for a consumer, using a computer 

10 terminal, to interact with a single payment system 

capable of paying all the consumer's bills whether by 
electronic means or by a paper check. Such a system 
now exists in the form of a consolidated bill payment 
system as described by Kight, et al. in U.S. Patent No. 

15 5,383,113, entitled SYSTEM AND METHOD FOR 

ELECTRONICALLY PROVIDING CUSTOMER SERVICES INCLUDING 
PAYMENT OF BILLS, FINANCIAL ANALYSIS AND LOANS. 

Although the consolidated bill payment system 
described by Kight^ et al. significantly advanced the 

20 state of the art, it did not focus on several problems 

which may arise in implementing a consolidated bill 
payment system capable of automatically paying consumer 
bills to merchants. One such problem is that consumers 
or data entry personal sometimes make mistakes in 
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entering payment data required by the bill payment system. 

Such a case arises when a consumer's account 
number with a merchant is incorrectly entered. The 
payment system must submit a correct account number to 
5 the merchant who will use this account number to 

associate the payment with the consumer. Thus, a 
technique is needed to validate the submitted 
consumer's account number. 

A data entry person may also enter payment data 

10 which incorrectly specifies the merchant's name or 

parts of the merchant's address. It has been found 
that merchant information such as the merchant name, 
address, zip code are typically mangled at the data 
entry stage. It has been further observed that errors 

15 will often be made upon entry of the zip code. The 

merchant's name, address, and zip code is typically 
required by the payment system in order to, for 
example, retrieve merchant records from the merchant 
database. If this data is incorrect, the payment 

20 system may be unable to retrieve the correct merchant's 

record for processing a payment. Thus, a technique is 
needed to correctly identify a merchant record 
notwithstanding the submission of erroneous merchant 
data. 
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A consolidated bill payment system must also have 
the capability to properly remit payments to the same 
merchant at more than one remittance center. Commonly 
a large commercial merchant, (e.g. , shoe company. Sears) 
5 will have several remittance centers distributed 

geographically so that customers can submit bills to a 
center within their location. Thus, a technique is 
required to ensure that consumer payments are remitted 
to the proper one of multiple remittance centers 

10 associated with the same. 

Advantageously, a consolidated payment system must 
also be able to handle the different processing formats 
and requirements of numerous separate merchant 
accounting systems. For example, each merchant's 

15 account system may require payment information, such as 

consumer account numbers, in a format different than 
that submitted by the consumer. For example, many 
merchant accounting systems will only accept an account 
nvimber with some portion of a consumer's last name or 

20 the consumer's zip code appended to the end of the 

account number presented by the customer. 

A merchant account system may even require an 
altered consumer account number which uniquely 
identifies the consumer. For example, two consumers, 

25 e-gw spouses, may have identical account numbers, but 
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the merchant accounting system may designate the 
account of each consumer uniquely, such as by combining 
the account number with the prospective customer's 
name. Additionally, It Is not unusual for a merchant 
5 to have different account numbers for a single 

customer. For example, an account number on an Invoice 
which goes out electronically may be different from an 
account number for the same customer which goes out as 
a paper transaction. 

10 Thus, a consolidated bill payment system must be 

able to handle the various formats required by the 
merchant accounting system of each merchant. 
Accordingly, a technique is required to transform 
payment data received from the consumer into a form 

15 compatible with a merchant's accounting system. 



Objectiv es of the Invention 

Accordingly, it is a general object of the present 
invention to provide a bill payment system capable of 
20 receiving bill payment data on behalf of consumers or 

corporate users via electronic means and automatically 
paying their bills to merchants. 

It is a further object of the present invention to 
provide a bill payment system capable of handling 
25 Incorrectly entered bill payment data. 
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In particular, it is an object of the present 
invention to correctly identify a merchant record based 
on received information which may include erroneous 
data. 

5 It is still a further object of the present 

invention to provide a technique for furnishing payment 
information, including a payor's account number with a 
merchant, in a format acceptable to a particular 
merchant accounting system. 

10 It is another object of the present invention to 

provide a technique for validating a consumer's account 
number with a merchant. 

It is another object of the present invention to 
provide a technique for ensuring payments are remitted 

15 to the proper remittance center. 

Additional objects, advantages, novel features of 
the present invention will become apparent to those 
skilled in the art from this disclosure, including the 
following detailed description, as well as by practice 

20 of the invention. While the invention is described 

below with reference to preferred embodiment (s) , it 
should be understood that the invention is not limited 
thereto. Those of ordinary skill in the art having 
access to the teachings herein will recognize 

25 additional implementations, modifications, and 
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embodiments, as well as other fields of use, which are 
within the scope of the invention as disclosed and 
claimed herein and with respect to which the invention 
could be of significant utility. 




Summary DisglQsurg of the Invention 

In accordance with the present invention, a 
communications network couples a payor station, working 

10 on behalf of a consumer or corporate user, and a payee, 

typically a merchant, to a programmed computer, or 
possibly a distributed system of computers, which 
processes payment requests, allowing them to 
communicate and exchange data between themselves. The 

15 communications network may be of any type facilitating 

the flow of information among the entities, such as a 
private network or the Internet. To process payment 
requests, a first station, e.g. a payor station, 
transmits payment information, including name, address 

20 data, and a payor's account number with one of perhaps 

thousands of payees and a second station, e.g. a 
payment processing server, receives this payment 
information and account number over the network. The 
payor station initiates payment on behalf of consumers 

25 or corporate users. The second station then processes 
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the payment information to produce an eleven digit zip 
code for the payee, and access a database of payees, 
typically merchants, to locate a payee record 
corresponding to the eleven digit zip code. In a 
5 further aspect of the present invention, the second 

station transforms the payor account number into an 
altered payor account number according to alteration 
rules. In a further aspect of the present invention, 
the payee has more than one remittance center and the 

10 second station is further configured to process an 

account number to identify a single remittance center 
in which to direct a payment which includes the altered 
payor account number. 

The first station collects payment requests from a 

15 plurality of consumers and feeds the requests to the 

second station. Typically, the second station is 
realized as a programmed general computer having a 
storage device and a processor. The storage device is 
configured to store a database of payee records and 

20 also includes alteration rules and validation rules for 

each payee. As will be understood by those skilled in 
the art, the storage device may be configured in any 
one of many arrangements to store and manage databases, 
and could include a long term bulk storage 

25 configuration, such as one or more hard disks. 
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The alteration rules can specify a wide variety of 
formats and may be realized as templates specifying 
fields or values, or as instructions for combining 
information from different fields. Typically, an 
5 altered account number is formed by combining the 

account number with some part of payment information or 
other information related to the payee. For example, 
the altered account number may include a portion of the 
payor's name, a portion of the payor's address, or a 

10 portion of the payor's zip code combined with the 

account number. 

According to another aspect of the present 
invention, validation rules for the account number are 
stored, and a determination is made as to whether the 

15 received account number conforms with the validation 

rules. The validation rules identify the expected 
general format for any payor account number associated 
with a payee. Validation rules are preferably realized 
as templates specifying fields or values, but may take 

20 on other forms, and may even be algorithms. For 

example, a check digit algorithm could process the 
account number and compare the result to a check digit. 

Preferably, the general computer of the second 
station is a mainframe or mini computer or high powered 

25 workstation, but could be any other processing device 
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capable of executing programmed instructions. 
Additionally, the general computer could be a 
distributed computer system in which various aspects of 
the system run on different platforms. The processor of 
5 the general computer is programmed to receive payment 

information, process the payment information, excluding 
zip code information, to produce an eleven digit zip 
code for the payee, access the database to locate a 
payee record corresponding to the eleven digit zip 

10 code, and then, preferably, makes an electronic payment 

to the payee after locating the payee record. The 
processor determines the eleven digit zip code 
preferably based on payee's name, and address, or some 
part thereof. However, the eleven digit zip code may 

15 also be determined based on other possible combinations 

of parts of the payment information, e.g. a portion of 
the payee's address. 

In a further aspect of the present invention, the 
processor verifies the account number conforms to the 

20 validation rules, and transforms the verified account 

number into an altered account number according to the 
alteration rules. 

In a further aspect of the present invention, the 
payee has a plurality of remittance centers, and the 

25 processor further processes the verified account number 



IPDC: 629.1 33500-00001 



10 




Docket No.: 33500-00001 

to identify a single remittance center of the plurality 
of remittance centers to which payment should be 
remitted . 

The processor's programed instructions can be 
5 stored on a storage medium. This article of 

manufacture may be portable, a floppy disk, a hard 
disk, a CD Rom, or other storage medium. The processor 
reads the programmed instructions from the medium and 
in accordance therewith receives payment information 

10 including a payor's account number, processes the 

payment information, excluding zip code information, to 
produce an eleven digit zip code for the payee, and 
preferably accesses the database to locate a payee 
record corresponding to the eleven digit zip code, and 

15 then, preferably, makes an electronic payment to the 

payee after locating the payee record. In another 
aspect of the present invention, the processor may also 
verify the account number based upon validation rules 
for account numbers associated with one of a plurality 

20 of payees, and preferably transform the account number 

into an altered account number based upon alteration 
rules of the one payee, and transmit the altered 
account number to the payee. 
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Brief Description of Drawings 

FIG. 1 is a system overview of a coxnputerized bill 
payment system in accordance with the present 
invention. 

5 FIG. 2 is a diagrammatical representation of the 

remittance payment processor system of Figure 1. 

FIG. 3 is a flow chart illustrating merchant 
identification in accordance with the present 
invention. 

10 FIG. 4 is a block diagram illustrating how 

merchant identification accesses the merchant database. 
J FIG. 5 is a flow chart illustrating account 

=P ranging in accordance with the present invention. 

- FIG. 6 is a flow chart illustrating account 

fU 15 scheming in accordance with the present invention. 

M Best Mod e for Carrying out the Invention 

FIG.l generally depicts a bill payment system 
including consumers 8, merchants 4, a batch file 
20 processing system 7, a remittance payment processor 

(RPP) 3, merchant banks 5, and consumer banks 6. 

A consumer, including a corporate user, (payor) is 
the individual or other entity for whom payments are 
actually made and whose account will be debited by the 
25 amount of the payment. The consumers 8 typically submit 



IPDC: 629.1 33500-00001 



12 




Docket No.: 33500-00001 

their payments electronically to batch file processing 
system 7, The batch file processing system 7 
represents any computer or network of computers capable 
of collecting payment requests from the consumers 8. 
5 Consumer banks 6 either physically or 

electronically holds money on account for consumers 8. 
These accounts are debited by the amount of any 
payments made on behalf of the consumers 8. 

Merchants (payees) 4 are the persons or other 
10 entities to whom payments are made via the bill payment 

^ system on behalf of consumers. Merchants may include 

+ department stores, the phone company, the paper boy, a 

credit card company, as well as other persons and 
^ entities to whom payments are made by one or more 

m 15 consumers 8. Merchants have accounts with merchant 

s - 

ifl banks 5. 

%i The remittance payment processor (RPP) 3, as shown 

in Figure 2, includes a memory 16 storing programmed 
instructions for carrying out the functions of the RPP, 
20 a processor 17 for executing these instructions, and a 

merchant database 18 storing information associated 
with the merchants. A batch file processing system 7 
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provides payment records collected from consumers 8 and 
transmits the batches of records to the RPP 3 . 

A network 1 connects the above-stated entities 
making communications between them possible. The 
5 network may be of any type capable of facilitating the 

flow of information among the various entities. It 
could, for example, be a public telecommunication 
network, the Internet, or other type of communication 
network. The network 1 may also be physically realized 
~ 10 as one or more networks. For example, in one possible 

embodiment, consumers 8 are coupled to batch file 

^ processing system 7 through one network and the batch 

P 

=C file processing system is coupled to the remittance 

5 payment processor (RPP) through another separate 

ry 15 network. 

ifl In operation, consumers 8 make payment requests 

electronically and these payment requests are collected 
by the batch file processing system 7. The batch file 
processing system 7 then transfers the payment requests 
20 collected from consumers 8 to the RPP 3 via the network 

1. Payment information for a consumer will include 
several different types of information, such as the 
consumer account number, the merchant name, and 
address • 
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FIG. 2 illustrates an overview of the process flow 
within the bill payment system of RPP 3. RPP 3 
receives payment information from the batch file 
processing system 7, processes that payment 
5 information, and passes the processed information to a 

component 24 which then makes payments to merchants 4. 
A payment is implemented by crediting a merchant's 
account electronically with a bank or other financial 
institution, or transferring a check or draft to the 

10 merchant. A payment implementation also includes 

sending advice to the merchant. Advice is information 
on a bill payment presented to a merchant 
electronically in a form that the merchant's system can 
use to process the bill payment transaction and update 

15 the merchant's records. One possible mode of payment 

to a merchant is electronic funds transfer through the 
Federal Reserve Automated Clearing House (ACH) Network 
26. Another electronic payment avenue is through the 
MasterCard RPS Network 30. Another remittance advice 

20 delivery mode is through Fax 22. Additionally, payment 

can also be made non-electronically to a merchant 
causing laser printer 28 to print a check 32 or a draft 
34. There is also a direct send 21 capability whereby 
the payment system sends advice to a merchant 4 . 



IPDC: 629.1 33500-00001 



15 




Docket No.: 33500-00001 

RPP 3 stores or processes several different record 
types necessary to the bill payment process. A 
merchant record contains all necessary information 
needed to forward a payment. This includes a merchant 
5 name, address, and zip code. A consumer record include 

a consumer name, address, zip code, and consumer 
account number. A payment record will contain 
information related to payment, including payee 
identification, consumer identification, and the dollar 

10 amount of the transaction. The merchant records are 

stored in a merchant database 18. All other records as 
well as programmed instructions which direct the 
operation of the RPP are stored in a memory 16. The 
memory 16 could also store the merchant database 18 if 

15 desired. 

After receiving payment records from the batch 
file processing system 7, the RPP periodically 
initiates a payment cycle 20 which process the records 
to generate information which will be used to credit 

20 merchant accounts and form advice for merchant systems. 

The processing flow of the billing cycle contains, in 
addition to other processes, three particularly 
important processes necessary for successful processing 
of each payment record. These processes are merchant 

25 identification 19a, account ranging 19b, and account 
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scheming 19c, typically performed in this order. In 
the first step of processing a payment record, merchant 
identification attempts to identify a merchant in the 
merchant database 18 based on information in the 
5 payment record. In the second step, the system will 

attempt to determine a remittance center of the 
merchant to which the billing information is sent. If 
a candidate remittance center is identified, the system 
enters the third stage of processing, account scheming. 

10 In account scheming, the system attempts to normalize a 

user account with a merchant according to the 
merchant's rules. If account scheming fails, the 
system will return to the account ranging process to 
attempt to identify another candidate remittance 

15 center, and from there, again into account scheming. 



Although the above described payment cycle is a 
preferable embodiment of the RPP, a payment cycle can 
include the three processes of merchant identification 

20 19a, account ranging 19b, and 19c, in any order or 

combination. In addition, these three processes may be 
performed independently, and could also be performed 
and packaged individually outside the RPP. These three 
processes will now be described in further detailed 

25 herein referring to FIGS 3-6. 
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FIG. 3 illustrates merchant identification. Using 
merchant identification, the RPP 3 is able to retrieve 
the correct merchant record from merchant database 18 
based on a consumer's payment record submitted with 
possibly erroneous merchant name and address 
information, e.g., street address, city, state, zip 
code. It has been observed that data entry operators 
will often make errors in the merchant's street address 
and zip code. The RPP 3 is capable of mapping the 
mangled merchant information supplied in the payment 
record into the proper merchant record in the merchant 
database 18 notwithstanding the errors in the merchant 
information. Merchant identification as described 
herein, can be used in any implementation where 
merchant information is likely to contain errors and 
must be mapped into an existing merchant record in the 
merchant database. 

RPP 3 initiates merchant ijifentif ication by step 60 
which retrieves a payment re^rd from one of the 
payment records previously submitted by the batch file 
processing system 7. ^he RPP will first attempt to 
retrieve a merchant y^ecord from the merchant database 
18 by matching th& merchant id included in the payment 
record against zhe records of the merchant database 18. 
If this is successful, the processing of the payment 
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record can continue to the payment direction4 stage 64. 

The payment directions stage is where the yRPP 

determines where to send payments. Thi^ stage includes 

account ranging discussed below which^determines the 

remittance center to which payment/gets sent. If there 

is no match, the RPP continues )io step 66. At step 66, 

the RPP maps the merchant's ifierchant name and address, 

excluding the provided sta^^et address and zip code, 

into an eleven digit code. That is, the RPP 

produces an eleven digit zip code based on merchant 

name, city, and axate in the payment information. In 

order to avail/ the merchant information which the 

inventors h/^e determined to be mostly likely to 

contain errors, the received merchant street address 

15 and zipr code are not considered. Hence, in step 66 the 

RPP IS identifies an eleven digit zip code based only on 

th^ merchant • s name, city, and state. 

Step 66 of merchant identification uses the 

indexing structure shown in Figure 4 to access one or 

20 more records from the merchant database 18. 

In step 66, the RPP 3 forms a 11 digit zip code 
Ana 

index 82 -fee^ associating the index entry with a merchant 
record in merchant database 18 via index 84. It may be 
possible that there is more than one merchant at a 
25 location identified by an eleven digit zip code. For 
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example, there could be a remittance processing center 
on the floor of the building identified by the eleven 
digit zip code which handles payments for several 
merchants 4. In such a case, the RPP differentiates 
5 the correct merchant record from other possibly correct 

merchant records associated with the same eleven digit 
zip code by, after identifying merchant records indexed 
to the same eleven digit zip code, comparing some 
portion of the merchant's name, e.g., the first five 

10 characters with the characters of each merchant ' s name 

which has been combined with the application zip code 
in the merchant index. The RPP 3 is thereby able to 
uniquely identify the proper merchant record. 

If step 66 identifies a unique merchant record 

15 processing continues to step 64. However, if step 66 

retrieves more than one merchant forming a group of 
records 86, then at step 67 the RPP 3 will attempt to 
match one or more characters of the merchant's name 83 
against the records 86 to identify a merchant record. 

20 If a match is found, processing continues to the 

payment directions stage 64. If there is no match, 
then the RPP will handle this contingency at step 68. 
If there is no merchant, the system may have provisions 
at step 68 for adding the merchant to the merchant 

25 database 18. 
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FIG. 5 illustrates a payment direction stage, as 
performed in the preferred embodiment of the present 
invention, in which the RPP attempts to determine a 
remittance center to which payment is sent. The RPP 
5 determines a remittance center based on one or more of 

the following identification rules: 1) length of 
account number, 2) merchant zip code, 3) merchant name, 
and 4) account ranging. Each rule has in common that 
it identifies the remittance center based on some 

10 factor of the payment information. 

In Figure 5, the RPP 3 processes the payment 
record presented in step 51 to determine one of a 
plurality of remittance centers associated with the 
applicable merchant in which to make payment. In step 

15 53, the RPP chooses one of the above-mentioned four 

rules and at step 55 attempts to identify a remittance 
center. If a remittance center is found at step 56, 
then the RPP directs payment to that remittance center 
58. If the RPP is unsuccessful in determining a 

20 remittance center, the RPP cycles back to step 53 and 

picks a new rule for identification. By this process, 
the system cycles through all combinations of rules 
that identify remittance centers for the merchant. 
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In account ranging, the correct remittance center 
is determined based on some characteristic of the 
consumer's account number. Typically a large merchant, 
such as credit card company will have multiple 
5 remittance centers to which respective consumer 

payments must be submitted. The payment record 
contains information which may be used to identify a 
remittance center besides an account number, such as an 
area code of the payor's telephone number. A telephone 

10 phone utility might include each consumer's area code 

in the consumer's account number and require payments 
from all consumers within a particular area code be 
directed to a particular one of multiple remittance 
centers. A credit card company may require that 

15 payments from all consumers having the same first six 

digits in their account numbers be made to the same 
remittance center. 

The payment direction process illustrated in 
Figure 5 is a preferred embodiment for determining 

20 payment direction. In this embodiment, the payment 

direction process includes account ranging as one of 
four possible methods of identifying a remittance 
center. However, in other embodiments, account ranging 
may be used in different combinations, or 

2 5 independent ly . 
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FIG. 6 illustrates the steps for account scheming. 
In certain cases, the consumer account number received 
by the RPP as part of the payment information may 
contain errors. Hence, the RPP has no way of checking 
5 the account number against a previously stored account 

number associated with the applicable consumer to 
verify the accuracy of the received information. 

Using account scheming, the RPP receives, in step 
12a, the consumer account number as part of the payment 

10 record. In step 42, the RPP checks to validate the 

account number. Then in step 46, the RPP alters the 
account number to correspond to a format required by a 
merchant's system 4 for processing. 

More particularly, the RPP validates and alters 

15 the consumer account number by storing separate 

business rules for each merchant which identify the 
expected general format for any consumer account number 
associated with that merchant. These business rules 
are stored as validation templates 40 in merchant 

20 database 18 for each merchant. The account number 

received from the consumer is checked against the 
validation template to validate that the account number 
conforms to the general account number format to which 
an account number associated with the applicable 

25 merchant must conform. For example, the validation 
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template for a merchant such as a credit card company 
may require an account nximber begin with the numbers 
"43" and be 18 digits long. Additionally, for some 
merchants the validation template will have check digit 
5 requirements. That is, the validation template can be 

used to confirm that the received consumer account 
number conforms to a check digit after being run 
through a specific algorithm. 

In operation, the RPP 3 performs, in accordance 
3 10 with programmed instructions stored on the memory 16, 

D the validation procedure by comparing in step 42 the 

p received consumer account number for the applicable 

p merchant received in step 12a with the validation 

template, say 40, for that merchant to test the 
y 15 validity of the account number. If that account number 

^ is not valid, the payment directions are rejected as 

^ not valid in step 43; otherwise, the account number is 

considered valid. 

Once the account number has been validated, it is 
20 then modified in step 46 so as to conform to alteration 

rules 44 for the applicable merchant. The alteration 
rules 44 are also stored in database 18. The 
alteration rules 44 relate to the format of the 
consumer's account number in which the applicable 
25 merchant system requires to process a consumer's 
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payment. Typically, alteration rules would specify an 
altered account number which includes a portion of a 
payor's name with the account number, a portion of the 
payor's address with the account number, or a portion 
5 of the payor's zip code with the account number. 

Alteration by the RPP 3 involvesy^ ^notif y ing ' the received 
account number which will be furnished, along with 
payment, to the merchant. For instance, some merchant 
systems require that the consumer's account number 
G 10 always end in "120". Hence, in such a case, the RPP 3, 

in accordance with programmed instructions stored on 
=C the memory 16, modifies the received account number to 

£, append "120" to the end of the alpha-numeric sequence 

= of the received account number. Once the account 

hi 15 number has been modified so as to conform to the format 

required by the merchant system, the altered account 
rj number 47 is then transmitted from the RPP 3 to the 

merchant 4 via the network 1, along with the payment, 
in step 48. 

20 It will also be recognized by those skilled in the 

art that, while the invention has been described above 
in terms of one or more preferred embodiments, it is 
not limited thereto. Various features and aspects of 
the above described invention may be used individually 

25 or jointly. Further, although the invention has been 
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described in the context of its implementation in a 
particular environment and for particular purposes, 
e.g. a bill payment system, those skilled in the art 
will recognize that its usefulness is not limited 
thereto and that the present invention can be 
beneficially utilized in any number of environments and 
implementations. Accordingly, the claims set forth 
below should be construed in view of the full breadth 
and spirit of the invention as disclosed herein. 

The present invention is not to be limited in 
scope by the specific embodiments described herein. 
Indeed, various modifications of the present invention, 
in addition to those described herein, will be apparent 
to those of skill in the art from the foregoing 
description and accompanying drawings. Thus, such 
modifications are intended to fall within the scope of 
the appended claims 
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